Re: Re: [GENERAL] +/- Inf for float8's

Поиск
Список
Период
Сортировка
От Henry B. Hotz
Тема Re: Re: [GENERAL] +/- Inf for float8's
Дата
Msg-id v04210176b5c73dae36fa@[137.78.84.130]
обсуждение исходный текст
Ответ на Re: Re: [GENERAL] +/- Inf for float8's  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
At 1:25 AM -0400 8/21/00, Tom Lane wrote:
>"Ross J. Reedstrom" <reedstrm@rice.edu> writes:
> > !     if (isnan(a))
> > !         PG_RETURN_INT32(1);
>
>Do not like this at all --- doesn't it make the result of btint4cmp(NaN,
>NaN) dependent on which argument chances to be first?  Seems to me that
>you must consider two NaNs to be equal, unless you want to subdivide
>the category of NaNs.

I'm pretty sure IEEE 754 says that NaN does not compare equal to 
anything, including themselves.  I also believe that Infinity isn't 
equal to itself either, it's just bigger than anything else except 
NaN (which isn't littler either).

Without having seen the start of this thread I think the biggest 
problem is that some of the results of compares depend on the mode 
that the FP hardware is put in.  IEEE specifies some modes, but not 
how you set the mode you want on the system you are actually running 
on.  For example I think comparing zero and -Infinity may return 
three possible results:  0 > -Infinity, 0 < -Infinity (because it was 
told to ignore the sign of Infinity), or an illegal value exception. 
Likewise signalling/non-signalling NaN's act different depending on 
mode settings.

We need to first figure out what floating point behavior we want to 
support.  Then we figure what mode settings provide that behavior 
with a minimum of overhead.  Then we need to figure out how to set 
those modes on all the platforms we support.  We will probably 
discover that not all required modes actually exist on all hardware 
platforms.  I know that 68000 and SPARC are pretty good, but PowerPC 
punted some stuff to exception handlers which may not be correct on 
all OS's.  I've heard that Java has some portability issues because 
Intel fudged some stuff in the newer hardware.

Does anyone feel like tracing down how to set the modes for all the 
different systems that we try to run on?  If there is interest then I 
might poke at a couple/three NetBSD ports and Solaris/SPARC.  But 
only if there is interest.

Sun has put some code out under GPL which will let you test for these 
special values and handle them, but that seems like a big hit for 
what should be a simple compare.  I assume that we can't put GPL code 
into the main sources any more than the *BSD's do.  Perhaps we could 
get away with it if it is only included if configure can't figure out 
how to set the modes properly?


Signature held pending an ISO 9000 compliant
signature design and approval process.
h.b.hotz@jpl.nasa.gov, or hbhotz@oxy.edu


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Ned Lilly
Дата:
Сообщение: Re: Bug tracking
Следующее
От: Hannu Krosing
Дата:
Сообщение: Re: Optimisation deficiency: currval('seq')-->seq scan, constant-->index scan